1. Field of the Invention
The present invention relates to computing systems and, more particularly, to data communications for computing systems.
2. Description of the Related Art
Recent developments in data communication for computing systems have software modules in a layered model. One feature of UNIX System V uses a layered model of software modules, referred to herein as the STREAMS model. The STREAMS model provides a standard way of dynamically building and passing messages through software modules that are placed in layers in a protocol stack. In the STREAMS programming model, the protocol stack can be dynamically changed, e.g., software modules can be added or removed (pushed and popped) at run-time. Broadly speaking, a “stream” generally refers to an instance of a full-duplex path using the model and data communication facilities between a process in user space and a driver which is typically located within the kernel space of the computing system. In other words, a stream can be described as a data path that passes data in both directions between a stream driver in the kernel space and a process in user space.
FIG. 1 illustrates a STREAMS programming environment 100 including a stream head 102, stream modules 104 and 106, and a streams driver 108. An application program can create a “stream” by opening a device 110. Initially, the stream includes only the stream head 102 and stream driver 108. The stream head 102 is the end of the stream closet to the user process and serves as a user interface between the stream and the user process. Similarly, the stream driver 108 is the end of the stream closest to the device 110 and transfers data between the kernel and the device 110.
After the stream head 104 and stream driver 108 are provided, one or more stream modules, such as stream modules 104 and 106, can be pushed on the stream between the stream head 102 and stream driver 108. An application can dynamically add or remove (push or pop) stream modules on the stream stack at run-time. Each of the stream modules 104 and 106 includes a defined set of kernel-level routines and data structures to process data that passes through these modules. For example, stream modules can operate to convert lower case to upper case, or to add network routing information, etc.
As depicted in FIG. 1, each of the stream head 102, the stream modules 104 and 106, and the stream driver 108 has a pair of queues that can be used as containers for holding messages (e.g., data) traveling upstream or downstream over the stream. For example, a down-queue 112 and a up-queue 114 hold blocks of messages (data) for the stream module 104 and respectively pass the data up the stream to the stream head 102 or down the stream to the stream driver 108. The messages can be ordered within the queues 112 and 114 in first-in first-out basis (FIFO), perhaps according to assigned priorities.
It should be noted that in some situations messages cannot be placed in queues 112 and 114. For example, when a stream queue has reached it allotted size, messages can no longer be placed in that queue. As another example, messages cannot be placed in the queues 112 and 114 when other processing threads have acquired their software locks. In such cases, messages are stored in another queue that can serve as a back-up queue, herein referred to as a “synchronization queue”. For example, synchronization queues 116 and 118 depicted in FIG. 1, respectively hold messages that could not be placed into the queues 112 and 114. It should be noted that in the STREAMS model, some stream modules (e.g., Internet Protocol (IP) module) are confined to having only one synchronization queue. As a result, for some stream modules there is only one synchronization queue available to serve as a backup queue. For example, a synchronization queue 120 which is used to hold the messages for the second software module 106.
One problem with conventional implementations of the STREAMS model is that in some instances messages cannot be propagated concurrently by two or more threads (or processes) running on different processors. For example, when a stream module has only one synchronization queue available, access to the synchronization queue cannot conventionally be achieved by two or more threads. This is partly attributed to the fact that in conventional implementations of the STREAMS model that messages can be intermixed in one synchronization queue regardless of their type and/or relative priority. Accordingly, access to the synchronization queue is limited to only one thread at a time. Typically, in conventional implementations of the STREAMS model, a synchronization queue lock is provided to exclude all the threads from accessing the synchronization queue except one single thread which has acquired (or possesses) the synchronization queue lock. For example, a synchronization queue lock can be provided to limit access to the synchronization queue 120 to only one thread at any given time (not shown).
In view of the foregoing, there is a need for improved methods for managing data propagation between software modules.